Thanks for this effort, seems to work well!

I'm not sure if I like the approach with the visible prop, even though it works.
It seems like the only reason we are introducing the visible prop in the new Container component is for this use case.
I would prefer if we were able to make it work like you mentioned, even though it's more challenging:

to actually do a "tabbed container" which would automatically swap items

I think this alternative sounds a lot better and more intuitive.
But we would probably need a new type of element prop that can take a list of children, as opposed to just one (elementList maybe?). The same thing as the children prop in the Paper component, for example, but with a list of views instead of a single view.

Then in the Tabs component logic we could make it render the correct view according to the active tab.

This might require special logic in the render overlay or the page view state so that when we dropped an element in an elementList slot, this element is added to the correct tab... I'd have to look into it deeper to see if there would be many more obstacles, or if this would be a good way to do things, but this is at least where I would start.

I'm not sure if I like the approach with the visible prop, even though it works.
It seems like the only reason we are introducing the visible prop in the new Container component is for this use case.

At the moment yes, there is nothing else that could use this prop, however I think controlling visibility is something that we currently lack in general and it should be useful. I.e. if we built a form with checkbox/radio and expected that some content would appear depending on selection, this component could also be used. Unless we decide on some different method to control visibility of components

At the moment yes, there is nothing else that could use this prop, however I think controlling visibility is something that we currently lack in general and it should be useful. I.e. if we built a form with checkbox/radio and expected that some content would appear depending on selection, this component could also be used. Unless we decide on some different method to control visibility of components

Yeah that's a good point. It sounds fine to me to keep the prop in the Container component, at least it sounds better than having this prop in every component... Unless it can be controlled with the sx prop?

Interesting! I think for now this looks good to me.
QQ: Is it possible for this container component to have sx prop? The Reason I am asking it is, I tried previewing tabs, and they appear like shown below, if there was an option to add border to a container then I could entire page in a container (like paper but without any elevation)

QQ: Is it possible for this container component to have sx prop?

@prakhargupta1 yes ofc, I can add it. I just wanted to share this option quickly, but if we are fine with intermediate solution then I can improve it as much as needed and work on tabbed container improvements in follow up

We will need to expand on the 'object' argtype, to include its properties. That way we can resolve it recursively in the runtime and find and render nested children and replace them in the object before we pass it as props to the component.

export interface ObjectValueType extends ValueTypeBase {
  type: 'object';
  /** @deprecated lets remove this: */
  schema?: string;
  properties?: Record<string, PropValueType>
}

export interface ArrayValueType extends ValueTypeBase {
  type: 'array';
  /** @deprecated lets remove this: */
  schema?: string;
  items?: PropValueType
}

that way we can define something like:

argTypes: {
  tabs: {
    typedef: { 
      type: 'array',
      items: {
        type: 'object',
        properties: {
          label: { type: string },
          content: { type: 'element' }
        }
      }
    }
  }
}

Not 100% sure this will be enough to solve the tabs problem. To be further investigated.

I think this should happen as a separate effort from adding new components

@apedroferreira added sx prop with defaults for padding and border as @prakhargupta1 requested

I'm not sure about the tabs. It feels like a Select to me with a different UI. I'm not sure how the migration path from this towards a real tabs component would work. Would it make more sense to have "tabs" as an option on the Select component? That way we keep the Tabs available for implementing real tabs, with surface one can build UI in?

One thing to note is that the container allows users creating flows that cause vertical layout shift, which is something we have avoided up until now.

I'm not sure about the tabs. It feels like a Select to me with a different UI. I'm not sure how the migration path from this towards a real tabs component would work. Would it make more sense to have "tabs" as an option on the Select component? That way we keep the Tabs available for implementing real tabs, with surface one can build UI in?

retool has both Tabs and TabbedContainer which I guess would be "real tabs" as you call it. IMO having Tabs placed under Select would significantly impact it's discoverability.

One thing to note is that the container allows users creating flows that cause vertical layout shift, which is something we have avoided up until now.

Avoided intentionally? Or is this just part of a change with new features? Also if ensuring no layout shifts happens is so important, users can use containers with fixed height via sx prop I assume.

Retool ended up with a lot of components that kinda do the same, but different. And I'm not sure that it's such a good thing. Why would you need Tabs if you have Tabbed container? The latter will do for 99% of the use-cases. And former has an equal status as a component for its niche use-case. IMO it would make more sense to have a set of core components that do 99% of the work and put all the niche ones further away.

But now that I think of it, we can always migrate the current Tabs as an option under Select when the time comes. So nevermind.

Avoided intentionally?

It was avoided intentionally. The main idea was that by default, when it comes to building good UX, users should fall in a pit of success. Making it hard to build layout shifting UI was part of that. But users were always able to circumvent with the sx prop, so I'm not saying this should be a hard rule. Just sharing design considerations that were adhered to up until now.